drizzlefandomcom_it-20200215-history
Discussioni aperte
=Licenze= *licenza del server - GPL2, perchè la ereditiamo. *licenze per plugin e client - qualunque (GPL2, BSD dice Brian) *polizza/accordo con i contributor -- nessuno *licenza documentazione (GFTL o Creative Commons o entrambe) *opzioni pacchetti/repository - apache fa così, dice Brian) =BZR= * sul wikia - come iniziare a usare bzr (c'è già del materiale, anche in italiano) * branch principale, solo 2 persone hanno accesso (Brian è una delle due). Il branch principale si chiama "trunk" * Brian estrae roba e la testa quotidianamente. * Jay, Monty e Stewart prendono dai branch degli altri, uniscono i contributi con il loro branch e poi fanno il push per Brian, che unisce tutto nel trunk * Brian's vision is that the test czar will be like a Jay, Monty or Stewart; except never committing anything else, just the test subtree. When you commit, commit on one idea/"unit of work" at a time. =Cose varie= * sul wiki - Perchè ci dovrebbe interessare un paragone con sqlite? * risposte in launchpad o utilizzare i blueprint segnandoli come informativi. * drizzle doc mailing list? * spiegare PERCHE' non supportiamo i prepared statements lato server (è sempre stato così, erano disabilitati sul server), ma li abbiamo lato client. * ha innodb, ha le transazioni * C'è bisogno di un client asincrono * Importare il plugin di Innodb nel trunk * Le dipendenze nel client non sono una buona idea * Ifdef per le librerie va bene, per le strutture no. * Rimuovere i tab tranne che in makefile.am (solo il primo) * sul wiki - lo stile di codice vim.rc (codice stile BSD con tab di 2 spazi) hg.tangent.org/vim.rc =Sistema di test= * Non stiamo utilizzando quello di MySQL. (EXPLAIN non è deterministico, questo è un problema). Ogni test case è un file enorme con decine di centinaia di istruzioni SQL, se una fallisce, tutto il test case è disabilitato. Questo è sciocco. * Forse dovremmo utilizzare un protocollo di test come quello che usa Perl (TAP, testanything.org). Si presume che tutti abbiano Perl. * Basically whoever writes a good test system, it will get in. * do we embed the ?dpn? (Ronald) * Move to more like a unit test scenario, test/assertions/results in one file, set up/test/tear down methods, one tests config, another tests sql, third category is testing all the OS commands and options. wrap a few syntaxes around that, take error handling and concurrency testing into that. It's English-like, Ronald proposes translating to lua (as one option due to leverage of dpm Proxy). (small dsl (domain-specific language) around test libraries?) (Brian worries about lua because it's not installed everywhere) * Il testing è di alta priorità ora. * Test harness, someone will need to be responsible other than Brian Proposta per un nuovo protocollo di test (TP) =Principi di base che Brian segue= * ascoltare la gente * scrivere codice leggibile * tutto quello che Brian può passare a un altro, lo farà * ci sono alcune persone dalle quali Brian farà il pull ogni fiorno, queste persone fanno il pull dagli altri. L'idea è che gli alberi siano già un po' testati. (buildbot risolve parecchi problemi non di compilazione) * va bene fare degli errori, Brian crede nell'educazione, tutti sbagliano (anche Brian) * Mantieni pulito il codice -- tutto si dovrebbe compilare senza warning (o errori). Per ora i warning del compilatore sono trasformati in errori, quindi non vengono compilati. * Stile del codice -- era in un blueprint, ora è uno stub su wikia. =Technical direction= * Strip the server down, almost done with it. * SQL modes removed, flags removed, VIEWs removed, Brian likes VIEWs but it's going to be done right if it's going to be put back in (rewrite engine, which isn't how MySQL does it now). * added plugin points for UDFs, logging, ACLs (will bump to PAM or LDAP) * Current MySQL is going to a loosely designed plugin mode where things aren't transparent. Brian's not a fan. * Drizzle won't be treated as both C or C++ * Removing ZEROFILL and INT(x). * Fewer primitives now, more advanced types later. * Brian wants patches to go into bzr, not e-mailed. Category:Documentazione Sviluppatori Category:Implementazioni future en:Open discussions